Multimedia Broadcast Multicast Services, MBMS, is a point-to-multipoint interface specification for existing and upcoming 3GPP cellular networks. The interface specification is developed to provide for an efficient delivery of broadcast and multicast services. The specification is referred to as Evolved Multimedia Broadcast Multicast Services, eMBMS, when transmissions are delivered through an Long Term Evolution, LTE, network. eMBMS is also known as LTE Broadcast.
Typical application that may utilize the MBMS include radio broadcasting, live streaming video, mobile television, as well as file delivery and emergency alerts.
The third generation Partnership Project, 3GPP, has defined Multimedia Broadcast Multicast Services, MBMS, operation on Demand, MooD, within 3GPP Release 12. The prescribed solution is based on a Device Local HTTP Proxy Server, which is capable of forwarding media content received from a unicast content delivery network or from a broadcast content delivery network. A Moving Picture Experts Group, MPEG, Server and Network Assisted Dynamic Adaptive Streaming over HTTP, MPEG-DASH, based solution was studied and documented, informatively, in TR 26.946.
However, that 3GPP Device-Proxy solution has not been implemented, since the performance requirements on the device were considered too high. MPEG SAND has introduced server and network assistant DASH and is defined in MPEG as ISO/IEC 23009-5. SAND defines a set of messages, which can be used for QoE reporting and network assistance, for example:                Parameters Enhancing Reception, PER, messages that are sent from a DANE to a DASH client, and        Status messages that are sent from DASH clients to DANEs        
Some SAND messages have been adopted in 3GPP, see for example 26.247. Work is currently on-going to use a SAND out-of-band DANE to enable switching between unicast and broadcast (MooD). Parts of the prescribed solution is, informatively, described in TR 26.946-Section 7.2.4.
The prescribed SAND solution for switching between unicast and broadcast works in principle as follows:                The DASH Media Presentation Description, MPD, for example an XML document containing information about media segments, contains multiple representations. Some representations are only available for unicast retrieval. Some other representations are available for unicast retrieval and are also broadcasted inside of an MBMS coverage area.        The MBMS User Service Description, USD, contains information around switchable representations. The idea is that the DANE controls, which representations are available, when the device is in broadcast coverage and which ones not.        When starting the Streaming session, the DASH Player opens a SAND communication channel to the DANE, which is aware about unicast and broadcast coverage. The DASH Player is the steered using SAND PER messages.        
The current SAND based MooD solution, as documented in TR 26.946 and currently specified into TS 26.247 and TS 26.346, requires a prepared manifest (MPD). This manifest is called unified MPD. The manifest contains an absolute base URL so that the segments can be fetched from a different server than the manifest. Further, the manifest must contain unique based URLs for a local server and a remote server.
Formally, the Broadcast Multicast Service Center, BM-SC, is responsible to create and provide the unified MPD, including all the extra elements, to the MBMS User Equipment. Some of the information is the hostname of the local HTTP server. Every device vendor may select an own hostname, depending on other local services. Further, when only a subset of the representations of the manifest are broadcasted, i.e. in contrast to alternative representations, then the BM-SC would need to condition the manifest only to describe the broadcasted available representations.
At this stage, it is necessary to insert extra base URLs, so that certain representations or sets of representations can be controlled.
It is however preferred that the BM-SC or the MBMS client do not condition the manifest, i.e. for this particular switching situation between unicast and broadcast.
The problem may also be phrased more general. Many SAND messages require a unique identification of representations inside the manifest. The packager is responsible of creating the manifest according to the produced content. It seems to become a restriction and unnecessary constrain to require, that the packager creates a SAND compliant manifest, with all the SAND specific information in it. It is also not preferred to condition the manifest.